AWS DataSyncのSMBロケーションではSMBファイル共有名にマルチバイト文字を含めることができない件

SMBファイル共有名が⽇本語の場合、ロケーションの作成ができないって本当?

こんにちは、のんピ(@non____97)です。

皆さんはAWS DataSyncにおいて、SMBロケーションではSMBファイル共有名が⽇本語の場合、ロケーションの作成ができないというのが本当なのか気になったことはありますか? 私はあります。

AWS Black Belt Online SeminarのAWS DataSyncの資料を確認するとファイル共有名が⽇本語の場合、ロケーションの作成ができない（2024 年 8 ⽉ 23 ⽇現在）と記載がありました。

抜粋 : AWS Black Belt Online Seminar AWS DataSync

これは2024/10/14現在でも継続して存在する制限なのでしょうか。

ファイル共有名を日本語で部署名やプロジェクト名にしているケースは多くあると考えます。現在もこの制限があるのであれば、何か回避する方法はないのでしょうか。

実際に確認してみました。

いきなりまとめ

• 2024/10/14現在でもSMBロケーションではSMBファイル共有名にマルチバイト文字が含まれる場合、ロケーションの作成はできない
  • パターン : ^[a-zA-Z0-9_\-\+\./\(\)\$\p{Zs}]+$
• Amazon FSx for NetApp ONTAPのロケーションではSMBファイル共有名にマルチバイト文字が含まれていてもロケーションの作成が可能
  • パターン : ^[^\u0000\u0085\u2028\u2029\r\n]{1,255}$
• 回避方法は以下の2パターン
  1. ファイル転送したいファイル共有と同じパスを持つ転送用ファイル共有をパターンに当てはまる名前で作成し、転送する
     • メリット
       1. 考え方がシンプル
     • デメリット
       1. 転送したいファイル共有の数と同等の数のファイル共有を作成する手間がかかる
       2. 転送したいファイル共有の設定を変更した場合、同様に転送用に用意したファイル共有の設定を変更する必要がある
       3. SMBサーバーを指定したときに表示されるファイル共有一覧の量が増え、ユーザーが混乱する可能性がある
          • 緩和策として、転送用ファイル共有の名前のプレフィックスとしてmigration_のようにプレフィックスを付与すれば、多少は見やすくなる
       4. DataSyncタスクをファイル共有分だけ作成することになるため、その分ENIを作成することになり、転送先リソースが存在するサブネットで多くのIPアドレスの割り当てが必要
  2. ファイル転送したいファイル共有のパスの上位ディレクトリにパターンに当てはまるファイル共有名を作成し、Includeで転送対象がファイル共有のパスになるように絞る
     • メリット
       1. 作成するファイル共有数が少ない
       2. 設定するDataSyncロケーション数が少ない
       3. 作成するDataSyncタスクが少ない
          • IncludesやExcludesの調整をする際はオプションを上書きして開始するで実施
     • デメリット
       1. 送信元および送信先のディレクトリ構造に細心の注意を払う必要がある
• EC2インスタンスのDataSyncエージェントはインスタンスタイプが2xlarge以上でなくとも動作はする

やってみた

検証環境

検証環境は以下のとおりです。

AD DC上に作成したファイル共有は以下のとおりです。

検証では以下のファイル共有を使用します。いずれのパスも同じC:\SMB shareです。

• SMB 日本語共有
• SMB日本語共有
• SMB_share

C:\SMB share配下の構成は以下のとおりです。

C:\SMB share>tree /f
Folder PATH listing
Volume serial number is F214-E54F
C:.
└───SMB日本語フォルダ
        SMB テキスト.txt

Amazon FSx for NetApp ONTAP(以降FSxN)上に作成したファイル共有は以下のとおりです。

検証では以下のファイル共有を使用します。いずれのパスも同じ/vol_ntfs/SMB shareです。

• FSxN 日本語共有
• FSxN日本語共有

ONTAP CLIで確認すると以下のとおりです。

::> cifs share show -share-name FSx*
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            FSxN          /vol_ntfs/SMB     oplocks             Everyone / Full Control
               日本語共有    share             browsable
                                               changenotify
                                               show-previous-versions
svm            FSxN日本語    /vol_ntfs/SMB     oplocks             Everyone / Full Control
               共有          share             browsable
                                               changenotify
                                               show-previous-versions
2 entries were displayed.

DataSyncエージェントの作成

まず、送信元のロケーションがSMBとAWSのマネージドサービスではないため、DataSyncエージェントを作成する必要があります。

DataSyncエージェントをEC2インスタンスで用意する場合の要件を確認すると、それなりの大きさのインスタンスタイプが要求されるようです。

Amazon EC2 インスタンスの要件
Amazon EC2 DataSync インスタンスにエージェントをデプロイする場合、インスタンスサイズは 2xlarge 以上である必要があります。

以下のインスタンスサイズのいずれかを使用することをお勧めします。

• m5.2xlarge: 最大 2,000 万個のファイルを転送するタスクに適しています。
• m5.4xlarge: 2,000 万個を超えるファイルを転送するタスク用です。
• snc1.medium: デバイス上で実行されているエージェント用。AWS Snowconeこのインスタンスは 2 つの CPU コアと 4 GiB のメモリを備えています。

AWS DataSyncエージェント要件 - AWS DataSync

より小さいインスタンスタイプでも動作するのか気になったので、今回はt3.mediumで作成します。

作成後、コンソールからステータスを確認しましたが、DataSyncエージェントのEC2インスタンスは問題なく起動できているようです。

アクティベーションキーの取得を行います。自端末とDataSyncエージェントのEC2インスタンスはVPN経由で繋がっていないので、EC2インスタンスのパブリックIPアドレスをエージェントのアドレスに指定します。

キーを取得するをクリックすると、自端末からHTTPでDataSyncエージェントに対してアクセスしようとします。

正常に処理が完了すると、アクティベーションキーの取得が完了します。

ということで、DataSyncエージェントを作る分であれば2xlarge 以上であるという要件は気にしなくとも大丈夫そうです。

SMBのロケーション作成

それではSMBのロケーション作成を行います。

SMBロケーションとしてAD DC(10.0.0.139)のSMB 日本語共有を指定します。

この状態でロケーションを作成するをクリックすると1 validation error detected: Value 'SMB 日本語共有' at 'subdirectory' failed to satisfy constraint: Member must satisfy regular expression pattern: ^[a-zA-Z0-9_\-\+\./\(\)\$\p{Zs}]+$とエラーメッセージが出力されました。

エラー文の正規表現パターンに含まれる文字はそれぞれ以下を表しています。

• a-z : 小文字のアルファベット
• A-Z : 大文字のアルファベット
• 0-9 : 数字
• _ : アンダースコア
• - : ハイフン
• + : プラス記号
• . : ドット
• / : スラッシュ
• ( : 開き括弧
• ) : 閉じ括弧
• $ : ドル記号
• p{Zs} : UnicodeのWhite Spaceカテゴリ

要するに日本語のようなマルチバイト文字は含まれていません。

CreateLocationSmbというSMBのロケーションを作成するAPIにも受け付けるパターンが記載されていました。

Subdirectory
SMB ファイルサーバーによってエクスポートされ、 DataSyncデータの読み取りまたは書き込みが行われる共有の名前を指定します。共有パスにはサブディレクトリ (例:) を含めることができます。/path/to/subdirectoryネットワーク内の他の SMB クライアントもこのパスをマウントできることを確認してください。

指定したサブディレクトリ内のすべてのデータをコピーするには、SMB 共有をマウントし、 DataSync そのすべてのデータにアクセスできる必要があります。詳細については、SMB ユーザーロールに「必要なアクセス許可」を参照してください。

型: 文字列

長さの制限: 最大長は 4,096 です。

パターン: ^[a-zA-Z0-9_\-\+\./\(\)\$\p{Zs}]+$

必須: はい

CreateLocationSmb - AWS DataSync

ファイル共有名に日本語を含む場合、DataSyncによるセルフマネージドのSMBサーバーからのファイル転送は諦めるしかないのか

では、ファイル共有名に日本語を含む場合、DataSyncによるセルフマネージドのSMBサーバーからのファイル転送は諦めるしかないでしょうか。

そんなことはありません。回避方法として「ファイル転送したいファイル共有と同じパスを持つ転送用ファイル共有をパターンに当てはまる名前で作成し、転送する」という手法があります。

検証環境の章で紹介しているとおり、1つのパスには複数のファイル共有を作成することが可能です。そのため、ファイル転送したいファイル共有と同じパスに対してパターンに当てはまるファイル共有名を作成してしまえば良いのです。

まず、日本語ファイル共有名と英語ファイル共有名のマッピングを行い、整理をします。

その後、マッピング結果に従い英語ファイル共有名のファイル共有を作成します。その際、パスと権限は日本語ファイル共有と同じものを設定します。

あとは英語ファイル共有をDataSyncロケーションとして設定して転送するだけです。

以下記事で紹介しているとおり、DataSyncはファイル共有の共有設定自体は転送しません。その共有配下のファイルやディレクトリのみを転送します。

https://dev.classmethod.jp/articles/test-the-ability-of-aws-datasync-to-transfer-shared-folder-settings/

そのため、ロケーションの名前が普段運用で使っているものと異なっていても、ファイル共有のパスが同じであれば、同様に転送することが可能です。

実際にSMB 日本語共有と同じパス、権限を設定したSMB_shareというファイル共有でロケーションを作成することができました。

FSxNのロケーション作成

次にFSxNのロケーションを作成します。

FSxNロケーションとしてマウントパスに/FSxN 日本語共有を指定します。

こちらはマルチバイト文字がふんだんに含まれていますが、問題なく作成できました。

APIで定義されているパターンを確認すると、FSxNロケーションはNULLや改行などの一部文字を含まなければ作成できるようです。

Subdirectory
データをコピーする SVM 内のファイル共有へのパスを指定します。

ジャンクションパス (マウントポイントとも呼ばれます)、qtree パス (NFS ファイル共有用)、または共有名 (SMB ファイル共有用) を指定できます。例えば、マウントパスは /vol1、/vol1/tree1、または /share1 かもしれません。

注記
SVM のルートボリュームにはジャンクションパスを指定しないでください。詳細については、『Amazon FSx for ONTAP ユーザーガイド』の「FSx for NetApp ONTAP ストレージ仮想マシンの管理」を参照してください。

型: 文字列

長さの制限: 最大長は 255 です。

パターン: ^[^\u0000\u0085\u2028\u2029\r\n]{1,255}$

必須: いいえ

CreateLocationFsxOntap - AWS DataSync

SMBロケーションも同様の正規表現パターンで受け付けてくれるとありがたいのですが、何か背景あるのでしょうか。

DataSyncタスクの作成

それでは、DataSyncタスクの作成をします。

送信元ロケーションの設定をします。

送信先ロケーションの設定をします。

フィルタで日本語を含む場合に対応できるかどうか確認したかったので、/SMB日本語フォルダ/*を指定します。

設定の全体は以下のとおりです。

正常にタスクが作成されたことを確認します。

DataSyncタスクの実行

DataSyncタスクの実行を行い、正常にファイル転送が行われるか確認しましょう。

作成したDataSyncタスクのデフォルト設定で実行を行います。

すると、3分ほどで実行ステータスが成功になりました。

CloudWatch Logsに出力されたログを確認すると、確かに意図した通りのファイルとディレクトリが転送されているようです。

2024-10-11T17:19:22.695+09:00 [INFO] Request to start task-099154a3034e0f892.
2024-10-11T17:21:23.253+09:00 [INFO] Execution exec-0fa3a58db177d6881 started.
2024-10-11T17:21:25.170+09:00 [NOTICE] Created directory /SMB日本語フォルダ
2024-10-11T17:21:25.772+09:00 [NOTICE] Transferred file /SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-11T17:21:25.848+09:00 [NOTICE] Transferred directory metadata /
2024-10-11T17:21:25.848+09:00 [NOTICE] Transferred directory metadata /SMB日本語フォルダ
2024-10-11T17:21:26.013+09:00 [NOTICE] Verified directory /
2024-10-11T17:21:26.013+09:00 [NOTICE] Verified directory /SMB日本語フォルダ
2024-10-11T17:21:26.013+09:00 [NOTICE] Verified file /SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-11T17:21:26.047+09:00 [INFO] Execution exec-0fa3a58db177d6881 finished with status Success.

転送完了したことをエクスプローラーからも確認します。

指定したFSxN上のファイル共有内から確認できました。

ツリーで表現すると以下のとおりです。

> tree "\\SMB-SERVER.corp.non-97.net\FSxN 日本語共有" /f
Folder PATH listing for volume FSxN 日本語共有
Volume serial number is 0000000F 801C:153E
\\SMB-SERVER.CORP.NON-97.NET\FSXN 日本語共有.
├───.aws-datasync
└───SMB日本語フォルダ
        SMB テキスト.txt

また、テキストも文字化けなく問題なく表示できました。

ということで「ファイル転送したいファイル共有と同じパスを持つ転送用ファイル共有をパターンに当てはまる名前で作成し、転送する」という対応で問題なく回りそうです。

DataSyncエージェントがt3.mediumで動作することを確認できたのも豊作です。

上位ディレクトリにファイル共有を作成し、転送する

「ファイル転送したいファイル共有と同じパスを持つ転送用ファイル共有をパターンに当てはまる名前で作成し、転送する」という対応方法を紹介しましたが、以下のような懸念点もあります。

1. 転送したいファイル共有の数と同等の数のファイル共有を作成する手間がかかる
2. 転送したいファイル共有の設定を変更した場合、同様に転送用に用意したファイル共有の設定を変更する必要がある
3. SMBサーバーを指定したときに表示されるファイル共有一覧の量が増え、ユーザーが混乱する可能性がある
4. DataSyncタスクをファイル共有分だけ作成することになるため、その分ENIを作成することになり、転送先リソースが存在するサブネットで多くのIPアドレスの割り当てが必要

3つ目については転送用ファイル共有の名前のプレフィックスとしてmigration_のようにプレフィックスを付与すれば、多少は見やすくなるでしょう。

ただし、1つ目と2つ目、4つ目の懸念点についてはどうしても発生します。

そこで考えられるのが「ファイル転送したいファイル共有のパスの上位ディレクトリにパターンに当てはまるファイル共有名を作成し、Includeで転送対象がファイル共有のパスになるように絞る」です。

C (ファイル共有名 : C$)
└─ SMB share (ファイル共有名 : SMB 日本語共有)
   └─ SMB日本語フォルダ

DataSyncロケーションでC$をファイル共有として指定した場合、/C$/SMB share/配下はDataSyncロケーションでSMB 日本語共有と指定した時の配下と同じになります。

一点注意する必要があるのは、「DataSyncロケーションで指定した共有名をトップディレクトリとして、以降のディレクトリ構造を維持して転送する点」です。

転送先のディレクトリ構造が以下のとき、DataSyncロケーションをFSxN 日本語共有と設定します。

/
└─ vol_ntfs
   └─ SMB share (ファイル共有名 : FSxN 日本語共有)

そして、DataSyncタスクの設定でIncludesを/SMB share/SMB日本語フォルダ/*として転送したとき、転送後のディレクトリ構造はディレクトリ構造パターン1になるのではなく、ディレクトリ構造パターン2になります。

/
└─ vol_ntfs
   └─ SMB share (ファイル共有名 : FSxN 日本語共有)
      └─ SMB日本語フォルダ

/
└─ vol_ntfs
   └─ SMB share (ファイル共有名 : FSxN 日本語共有)
      └─ SMB share
         └─ SMB日本語フォルダ

実際にやってみましょう。

共有名C$のロケーションを作成します。

C$のロケーションが作成できたことを確認します。

作成したロケーションを送信元ロケーションとしてDataSyncタスクを作成します。このとき、Includesを/SMB share/SMB日本語フォルダ/*とします。

タスクを実行すると、正常に完了します。

転送されたファイルを確認すると、確かにディレクトリ構造パターン2になっていることが分かります。

CloudWatch Logsのログは以下のとおりです。

2024-10-11T17:37:12.190+09:00 [INFO] Request to start task-0f2919f5da26467d3.
2024-10-11T17:39:19.686+09:00 [INFO] Execution exec-03fd1f8c218a2da7a started.
2024-10-11T17:39:21.614+09:00 [NOTICE] Created directory /SMB share
2024-10-11T17:39:21.615+09:00 [NOTICE] Created directory /SMB share/SMB日本語フォルダ
2024-10-11T17:39:22.184+09:00 [NOTICE] Transferred file /SMB share/SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-11T17:39:22.303+09:00 [NOTICE] Transferred directory metadata /
2024-10-11T17:39:22.304+09:00 [NOTICE] Transferred directory metadata /SMB share
2024-10-11T17:39:22.304+09:00 [NOTICE] Transferred directory metadata /SMB share/SMB日本語フォルダ
2024-10-11T17:39:22.479+09:00 [NOTICE] Verified directory /
2024-10-11T17:39:22.479+09:00 [NOTICE] Verified directory /SMB share
2024-10-11T17:39:22.479+09:00 [NOTICE] Verified directory /SMB share/SMB日本語フォルダ
2024-10-11T17:39:22.479+09:00 [NOTICE] Verified file /SMB share/SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-11T17:39:22.501+09:00 [INFO] Execution exec-03fd1f8c218a2da7a finished with status Success.

もし、今回ディレクトリ構造1のような形にしたいのであれば、DataSyncの送信先ロケーションをFSxN vol_ntfsと設定します。

/
└─ vol_ntfs (ファイル共有名 : FSxN vol_ntfs)
   └─ SMB share (ファイル共有名 : FSxN 日本語共有)

実際にやってみましょう。

FSxN vol_ntfsというファイル共有をFSxN上に作成します。

::> cifs share create -share-name "FSxN vol_ntfs" -path /vol_ntfs

::> cifs share show -share-name FSx*
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
svm            FSxN vol_ntfs /vol_ntfs         oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
svm            FSxN          /vol_ntfs/SMB     oplocks             Everyone / Full Control
               日本語共有    share             browsable
                                               changenotify
                                               show-previous-versions
svm            FSxN日本語    /vol_ntfs/SMB     oplocks             Everyone / Full Control
               共有          share             browsable
                                               changenotify
                                               show-previous-versions
3 entries were displayed.

送信先ロケーションをFSxN vol_ntfsとして、DataSyncタスクを作成します。

DataSyncタスク実行し、正常にタスクが実行完了したことを確認します。

Skippedで1 filesとなっているのは/SMB shareです。こちらのディレクトリは既に転送先に存在しているため、スキップされています。

転送先ロケーションの/SMB shareを確認してみましょう。

> tree "\\SMB-SERVER.corp.non-97.net\FSxN vol_ntfs\SMB share" /f
Folder PATH listing for volume FSxN vol_ntfs
Volume serial number is 000000A1 801C:153E
\\SMB-SERVER.CORP.NON-97.NET\FSXN VOL_NTFS\SMB SHARE
├───.aws-datasync
├───SMB share
│   └───SMB日本語フォルダ
│           SMB テキスト.txt
│
└───SMB日本語フォルダ
        SMB テキスト.txt

SMB share直下にSMB日本語フォルダが作成されていることが分かりますね。

エクスプローラーでも転送されたファイルを確認できました。

このとき、CloudWatch Logsに出力されたログは以下のとおりです。

2024-10-14T15:41:04.658+09:00 [INFO] Request to start task-0550eec6fdf747ccd.
2024-10-14T15:43:22.567+09:00 [INFO] Execution exec-0f5c617e14364842c started.
2024-10-14T15:43:22.589+09:00 [INFO] Started logging in destination hostId: host-008b2178864f7952c for Execution exec-0f5c617e14364842c
2024-10-14T15:43:22.614+09:00 [INFO] Started logging in destination hostId: host-01fa5e96acf54d9a7 for Execution exec-0f5c617e14364842c
2024-10-14T15:43:22.669+09:00 [INFO] Started logging in destination hostId: host-02e3ec5cf72ced923 for Execution exec-0f5c617e14364842c
2024-10-14T15:43:22.679+09:00 [INFO] Started logging in destination hostId: host-08e7661afee1f2446 for Execution exec-0f5c617e14364842c
2024-10-14T15:43:24.693+09:00 [NOTICE] Created directory /SMB share/SMB日本語フォルダ
2024-10-14T15:43:25.306+09:00 [NOTICE] Transferred file /SMB share/SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-14T15:43:25.432+09:00 [NOTICE] Transferred directory metadata /SMB share
2024-10-14T15:43:25.432+09:00 [NOTICE] Transferred directory metadata /SMB share/SMB日本語フォルダ
2024-10-14T15:43:25.652+09:00 [NOTICE] Verified directory /SMB share
2024-10-14T15:43:25.652+09:00 [NOTICE] Verified directory /SMB share/SMB日本語フォルダ
2024-10-14T15:43:25.652+09:00 [NOTICE] Verified file /SMB share/SMB日本語フォルダ/SMB テキスト.txt, 20 bytes
2024-10-14T15:43:25.710+09:00 [INFO] Execution exec-0f5c617e14364842c finished with status Success.

/SMB shareは既に転送先に存在していたので新規に作成はしていませんが、メタデータの転送は行われていることが分かります。

ということで、こちらの手法では送信元および送信先のディレクトリ構造に細心の注意を払う必要がありますが、作成するファイル共有の数を格段に減らすことが可能になります。

SMBファイル共有名に日本語が含まれる場合は注意しよう

AWS DataSyncのSMBロケーションではSMBファイル共有名にマルチバイト文字を含めることができない事象を紹介しました。

ロケーションタイプがSMBを使用する際に、SMBファイル共有名に日本語が含まれているかは十分チェックしましょう。もし、該当する場合は紹介した回避策で対応すると良いでしょう。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!